Currently, the blockchain technology is widely applied, and its decentralization mode ensures that data is not easily tampered with, thereby improving security.
In a practical application scenario, a blockchain can provide a corresponding service for a client, and a blockchain node can process a service request of a user and generate a corresponding processing result. However, the blockchain may include a malicious node or a faulty node. It undoubtedly affects the service obtained by the client. Therefore, for example, a Practical Byzantine Fault Tolerance (PBFT)-based consensus procedure can be performed between nodes in the blockchain, so that the nodes can agree on a correct processing result.
The PBFT-based consensus procedure is used as an example. As shown in FIG. 1, the PBFT-based consensus procedure includes a pre-prepare (pre-prepare) stage, a prepare (prepare) stage, and a commit (commit) stage. A node (a node numbered 0 in FIG. 1) that receives a service request from a client (represented by C in FIG. 1) sends the service request to other nodes (for example, nodes numbered 1, 2, and 3) for performing a consensus procedure. At each stage, the nodes send a consensus message to each other, so that the nodes perform a consensus procedure. After the three-stage consensus procedure, it can be considered that a consensus is reached. In this case, the nodes separately process the service request, and each feed back a processing result to the client.
In some scenarios in the existing technology, to process a large amount of consensus procedures, a plurality of servers are usually disposed in each node in the previously described blockchain, and different servers can separately participate in different consensus procedures, to improve a processing amount and processing efficiency of the blockchain.
However, in practice, a server in a node may be faulty, for example, may be offline or restarted. For example, in the PBFT-based consensus procedure, once a server is faulty, the server cannot continue participating in consensus and affects the probability of reaching a consensus. If a consensus is not reached at a certain round, consensus needs to be re-initiated from the pre-prepare stage, regardless of a consensus stage that the blockchain is currently at. Apparently, it undoubtedly affects blockchain consensus efficiency, and further affects service processing efficiency of the blockchain.